Local dev output fills up with things you never asked for. Your browser fetches a favicon on its own. Chrome DevTools probes for a workspace file on every page load. And under the Vite plugin, your Worker runs inside a runner Durable Object behind a couple of wrapper workers, so the traces fill with machinery that doesn't exist in production.

Two separate changes, one commit each.

Browser-made requests are logged at debug, not dropped

/favicon.ico and DevTools' /.well-known/appspecific/com.chrome.devtools.json move from info to debug in the wrangler dev request log. A default session is quiet; --log-level debug still shows every request the Worker served. Nothing is thrown away.

If the Worker returns a 5xx serving one of them it stays at info, so a handler that broke is never quietly demoted.

Vite's internal plumbing is hidden from the Observability views

Vite's own module-init and export-type requests were listed as traces, and its module-runner RPC dispatch as logs. In one real session that was 8 of 11 rows in the Traces list. None of it exists in a deployed Worker, so it's hidden, and the show/hide toggle it used to sit behind is gone.

Span-level hiding inside a trace already existed and was already on by default — what's new is the trace list and the Events view, neither of which filtered Vite at all.

Deliberately not included

Favicon requests still appear in the Observability views. An earlier version of this PR hid them there too, and that was wrong: the Events view is built to mirror the production Logs view, and favicon requests are real requests that do show up in production. Hiding them locally would make the mirror lie. The pre-existing code already drew this line — "Favicon requests are intentionally left in — they're at least driven by real navigation" — and only the DevTools probe, which is pure tooling traffic, stays filtered there.

That's also why the terminal change demotes rather than drops: the complaint was about noise in the terminal, and demoting fixes that without pretending a request didn't happen.

Notes on the Vite filtering

• Matched by URL path, not wrapper-worker name. Vite routes every request through its router worker, so matching a root span by name would have hidden all your real traffic along with the plumbing.
• The executeCallback rule only fires inside a trace already known to be Vite. A wrangler dev user can legitimately have their own RPC method with that name, and silently dropping their logs would be the worst outcome here.
• Failures are never hidden, and error-level logs always show.
• Filtering happens in SQL rather than on the returned rows, so LIMIT counts only what you'll actually see.

Checked against real capture stores from both a vite dev and a wrangler dev session, including that the Vite rules leave a wrangler dev session completely alone.

• Tests
  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: this is a local dev-experience refinement (reducing log/UI noise) with no new public API, binding, or config surface.